Blockchain network communication management

ABSTRACT

A device that is capable of sending/receiving telephony-based messages may communicate with a blockchain network without having a direct connection (e.g., internet connection) to the blockchain network. A message may be communicated via a telephony network to a telephony carrier system. The telephony carrier system may translate the telephony-based message into a blockchain-based communication and provide the blockchain-based communication to the blockchain network. In addition, an entity on the blockchain network may communicate with a device that does not have an internet connection to the blockchain network. The entity may initiate a blockchain-based communication that is received by an on-chain interface of a telephony network carrier. In response, the telephony network carrier may generate a telephony-based message and communicate the telephony-based message to the user device.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 16/384,762, filed on Apr. 15, 2019, which claims priority toU.S. Provisional Patent Application No. 62/722,076, filed on Aug. 23,2018, the contents of both of which are incorporated by referenceherein.

BACKGROUND

Electronic devices may be used to exchange information overcommunication networks. For example, electronic devices may communicatewith each over via the internet. In some cases, information regardingthe communications may be recorded in a distributed ledger, such as ablockchain. Blockchains are distributed in the sense that they storeinformation in blocks of records that are cryptographically linked anddistributed among many different devices. A blockchain is typicallyimmutable, which means that the information stored in the records cannotbe changed or deleted; information may only be added to the blockchainin the form of new records. The distributed nature of the blockchain andthe cryptographic linking of blocks within the blockchain facilitate theimmutability of the information stored in the blockchain.

BRIEF DESCRIPTION OF DRAWINGS

Throughout the drawings, reference numbers may be re-used to indicatecorrespondence between referenced elements. The drawings are provided toillustrate example embodiments described herein and are not intended tolimit the scope of the disclosure.

FIG. 1 is a block diagram of an illustrative computing environmentincluding a blockchain network, a telephony network, a telephony carriersystem, and a user device according to some embodiments.

FIG. 2 is a block diagram of various data flows and interactions betweena blockchain network and other systems and networks during processing ofa communication directed to a user device using on-chain logicalprocessing, according to some embodiments.

FIG. 3 is a block diagram of various data flows and interactions betweena blockchain network and other systems and networks during processing ofa communication from a user device to the blockchain network usingon-chain logical processing, according to some embodiments.

FIG. 4 is a block diagram of various data flows and interactions betweena blockchain network and other systems and networks during processing ofa communication directed to a user device using off-chain logicalprocessing, according to some embodiments.

FIG. 5 is a block diagram of various data flows and interactions betweena blockchain network and various other systems and networks duringprocessing of a communication from a user device to the blockchainnetwork using off-chain logical processing, according to someembodiments.

FIG. 6 is a block diagram of various data flows and interactions betweena blockchain network and various other systems and networks using apayment channel according to some embodiments.

FIG. 7 is a block diagram of various data flows and interactions betweena blockchain network and various other systems and networks using apayment channel and a communication from a user device to an entity onthe blockchain network according to some embodiments.

FIG. 8 is a flow diagram of an illustrative process to generateblockchain network communications from telephony-based messagesaccording to some embodiments.

FIG. 9 is a flow diagram of an illustrative process to generatetelephony-based messages from blockchain network communicationsaccording to some embodiments.

FIG. 10 is a block diagram illustrating components of a computing deviceconfigured to execute processes for blockchain network and telephonynetwork communication according to some embodiments

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present disclosure is directed to communication between a blockchainnetwork and devices on a telephony network. Conventionally, the optionsfor communicating with blockchain networks are limited to either (1)running a node of the blockchain network locally on the system that iscommunicating with the blockchain network, or (2) employing ablockchain-network-based service to communicate with the blockchainnetwork via remote procedure call (“RPC”) and Hypertext TransferProtocol (“HTTP”). In each of these situations, an internet connectionis required.

Aspects of the present disclosure address, among other things, theabove-referenced limitations with conventional methods of usingblockchain networks. In some embodiments, a device that is capable ofsending/receiving telephony-based messages (e.g., short message serviceor “SMS” messages) may communicate with a blockchain network withouthaving a direct connection (e.g., internet connection) to the blockchainnetwork. For example, a user may use a mobile phone to communicate withan entity on a blockchain network. The user may send a telephony-basedmessage addressed to a particular phone number, such as a phone numberassociated with the entity or with the blockchain network. The messagemay include data representing a blockchain transaction (e.g., a signedtransaction that includes address information and a payload alreadyformatted for processing by the blockchain network). The message may becommunicated via a telephony network (e.g., the public switchedtelephone network or “PSTN”) to a telephony network carrier system, suchas a telephony network carrier system associated with the user device orthe destination phone number. The telephony network carrier system (alsoreferred to herein as a “carrier system” for convenience) may providethe blockchain-based communication to the blockchain network. Fromthere, the blockchain-based communication may be handled as a nativeblockchain-based communication would be handled. As another example, anentity on the blockchain network may communicate with a device that doesnot have an internet connection to the blockchain network. The entitymay initiate a blockchain-based communication that is received by anon-chain interface of a carrier system. In response, the carrier systemmay generate a telephony-based message and communicate thetelephony-based message to the user device. Thus, a device may interactwith a blockchain network—in either a one-way or bi-directionalmanner—using telephony-based messages communicated over a telephonynetwork and without having a direct connection to the blockchain networkvia the internet.

Additional aspects of the present disclosure relate to variousinteractions with blockchain network-based functions usingtelephony-based messages. In some embodiments, a blockchain network mayprovide the ability to execute on-chain logic. For example, a blockchainnetwork may be configured to use “smart contracts” or other on-chaincomputer programs to provide features to users of the blockchainnetwork. A smart contract may perform various programmatic operations,such as transferring value (e.g., cryptocurrency tokens), transmittingmessages, recording data in the distributed ledger, monitoring for theoccurrence of events, enforcing rules, or performing other logicalfunctions. In one specific, non-limiting example, a device such as anautomated teller machine (“ATM”) may communicate with the blockchainnetwork and initiate the transfer of value from one account to anotherby transmitting a telephony-based message via a telephony network. Acarrier system may receive such a message, determine a blockchain-basedcommunication from the telephony-based message, and submit theblockchain-based communication to the blockchain network. A smartcontract on the blockchain network may receive or detect theblockchain-based communication, and begin execution (e.g., determiningwhether preconditions are met, processing a transfer of value, recordingdata regarding the transfer of value, etc.). If necessary, the smartcontract may generate a message for transmission back to the originatingdevice confirming successful execution of the smart contract or failurethereof.

Although aspects of some embodiments described in the disclosure willfocus, for the purpose of illustration, on particular examples ofblockchain networks, network interfaces, messaging protocols, and enduser devices, the examples are illustrative only and are not intended tobe limiting. In some embodiments, the techniques described herein may beapplied to various alternatives, such as other forms of distributedledger networks, other types of interfaces to blockchain networks, otherend user devices and communication protocols, etc. Various aspects ofthe disclosure will now be described with regard to certain examples andembodiments, which are intended to illustrate but not limit thedisclosure.

Example Computing Environment

With reference to an illustrative embodiment, FIG. 1 shows a computingenvironment in which aspects of the present disclosure may beimplemented. As shown, the computing environment may include ablockchain network 100, a carrier system 110, a telephony network 120,and various end user devices 130 a, 130 b. End-user devices 130 a and130 b may be referred to collectively as user devices 130, orindividually as a user device 130.

The blockchain network 100 may include various nodes 104 across which adistributed ledger—a blockchain 102 in this example—is distributed. Insome embodiments, a blockchain network 100 may include a plurality ofpeer nodes 104, with each peer node 104 storing a copy of at least aportion of the blockchain 102. Entities that want to utilize thefeatures of a blockchain 102 (e.g., immutable data storage, valueexchange, smart contracts or other on-chain logic, etc.) each implementa peer node 104.

The infrastructure on which blockchain network 100 is implemented may bereferred to as a “data network” to highlight its use as a network fortransmitting bit-encoded data. In some embodiments, the blockchainnetwork 100 may be implemented on a packet-switched data network 106,such as the internet. In some cases, the data network 106 may be atleast partially implemented using a private network, personal areanetwork, local area network, wide area network, etc., or somecombination thereof, some or all of which may or may not have access toand/or from the Internet. The peer nodes 104 of the blockchain network100 may communicate with each other using such a data network 106.

The example components of the blockchain network 100 shown in FIG. 1 areillustrative only and are not intended to be limiting. In someembodiments, a blockchain network 100 may have fewer, additional, and/oralternative components.

The carrier system 110 may include various components for providing thefeatures described herein. In some embodiments, the carrier system 110may include a carrier node 112 for communicating with the blockchainnetwork 100. For example, the carrier node 112 may be one of the peernodes of the blockchain network 100, and may be used by the carriersystem 110 to manage the transmission and receipt ofblockchain-network-based communications to and/or from the blockchainnetwork 100. Communication may also occur with various other peer nodes104 of the blockchain network 100. In some embodiments, the carriersystem 110 may include telephony carrier infrastructure 114 forcommunicating with the telephony network 120. For example, the telephonycarrier infrastructure 114 may include a telephony network gateway 116that manages transmission and receipt of messages (e.g., SMS messages)over the telephony network 120.

In some embodiments, telephony network 120 may be a circuit-switchednetwork or other telephone network. For example, telephony network 120may be a publicly-accessible telephone network, such as the PSTN. Insome cases, the telephony network 120 may be or include a privatetelephone network, such as a private branch exchange (“PBX”). In someembodiments, telephony network 120 may also include features fortransmitting bit-encoded data in a digital manner rather than merely inan analog manner. For example, the telephony network 120 may be orinclude a digital cellular telephone network.

The carrier system 110 may be implemented on one or more physicalcomputing devices that provide computing services and resources to usersof a telephony network 120. In some embodiments, the carrier system 110(or individual components thereof, such as the carrier node 112,telephony network gateway 116, etc.) may be implemented on one or morehost devices, such as blade servers, midrange computing devices,mainframe computers, desktop computers, or any other computing deviceconfigured to provide computing services and resources. For example, asingle host device may execute one or more carrier nodes 112, telephonynetwork gateways 116, other elements of carrier infrastructure 114, etc.The carrier system 110 may include any number of such hosts.

The example components of the carrier system 110 shown in FIG. 1 areillustrative only and are not intended to be limiting. In someembodiments, a carrier system 110 may have fewer, additional, and/oralternative components.

The user devices 130 are devices configured to send/receive text-basedmessages, multimedia-based messages, and/or various other messages overa phone network such as the telephony network 120. Such messages may bereferred to as telephony-based messages. For example, a user device 130may be configured with application software that provides SMS messagefunctionality to send text messages to other devices that also provideSMS message functionality. In some embodiments, user devices 130 mayalso or alternatively be configured to communicate telephone-basedmessages other than SMS messages, such as multimedia messaging service(“MMS”) messages, voice communications, and/or communications usingother telephone-based protocols. The carrier system 110 may beconfigured to communicate with the user devices 130 using suchtelephone-based protocols.

In some embodiments, the individual end-user devices 130 may be any of awide variety of electronic communication devices, including personalcomputing devices, terminal computing devices, laptop computing devices,tablet computing devices, electronic reader devices, wearable computingdevices, mobile devices (e.g., cellular and other mobile phones, smartphones, media players, handheld gaming devices, etc.), servers, midrangecomputing systems, mainframe computing systems, ATMs, and various otherelectronic devices and appliances.

Example Communications Between a Blockchain Network and a TelephonyNetwork

FIG. 2 shows example data flows and interactions between a blockchainnetwork 100 and other systems and networks during processing of acommunication directed to an off-chain user device 130 via on-chainlogic of a carrier system 110. Such messages may be referred to as“outbound messages” to highlight their direction as being outbound withrespect to the blockchain network 100.

An entity, such as a company or individual person, may use a user device130 to interact with the blockchain network 100. For example, the userdevice 130 may be a mobile phone that has access to the telephonynetwork 120, and a user of the user device 130 may have an account onthe blockchain network 100. The user may wish to receive messages thatoriginate from the blockchain network 100 or are otherwise transmittedvia the blockchain network 100, such as messages confirming the transferof value from one account to another account.

A message origin 210 on the blockchain network 100 may generateblockchain message data 212. Illustratively, the blockchain message data212 may represent an application programming interface (“API”) requestto send a telephony-based message to the user device 130. The messageorigin 210 may include on-chain logic, such as a smart contract thatmonitors for some event and transfers value to an account of the user inresponse to occurrence of the event. The blockchain message data 212generated by the message origin 210 may include data representing apayment 214 (e.g., the value to be paid to the carrier system 110 forproviding message transmission services to the message origin 210). Theblockchain message data 212 may also include a payload, such as datarepresenting an API request 216 to executed by the carrier system 110.

In some embodiments, the carrier system 110 may expose some or all ofthe carrier system's API to the blockchain network 100 via carrieron-chain logic 220. In this way, entities on the blockchain network 100may employ the services of the carrier system 110—including theexecution of off-chain logic through the use of an API request—over theblockchain network 100 without requiring separate off-chain access tothe carrier system 110. The carrier system 110 API that is exposed to—orotherwise accessible from—the blockchain network 100 may includefunctionality other than the mere sending of messages to user devices130 that are off-chain. For example, any other feature provided by thecarrier system 110 to its off-chain clients may be utilized via the APIthat is exposed to the blockchain network 100. In some embodiments, theon-chain logic 220 is deployed to the blockchain and is therefore partof the blockchain network 100. Illustratively, the on-chain logic (e.g.,smart contract) may represented by code that may be stored in theblockchain 102. When a message or other transaction invokes the on-chainlogic 220, the code is executed by one or more entities of theblockchain network 100, such as the carrier node 112, one or more peernodes 104, etc.

In one specific, non-limiting embodiment, the carrier system's off-chainAPI (or portions thereof) may be exposed to the blockchain network 100by generating an intermediate API specification of the off-chain API.The intermediate API specification may be a lightweight, standardizedrepresentation of the carrier-specific off-chain API. Advantageously,this standardized representation allows other entities to discover thefeatures provided by the API and generate API calls as long as theentities are configured to parse and process API specificationsrepresented using the standard. Illustratively, on-chain logic such as asmart contract may be configured to parse and process API specificationsrepresenting using the standard. Thus, an on-chain entity may interactwith the carrier system's off-chain API through the on-chain logic.

Returning to the example above, message origin 210 may generateblockchain message data 212 that is obtained by, detected by, orotherwise causes invocation of on-chain logic 220 (e.g., a smartcontract) of the carrier system 110. The on-chain logic 220 may performany necessary processing to extract or generate the API request 222 thatwill be received by the carrier node 112 of the carrier system 110. Forexample, the on-chain logic 220 may merely extract data representing theAPI request and then provide the API request 222 to the carrier node112. As another example, on-chain logic 220 may perform more intensiveprocessing to deserialize or otherwise generate the API request 222 fromthe API request data 216 in the blockchain message data 212. If theblockchain network 100 allows inexpensive or free execution of on-chainlogic, then performing this processing in a smart contract of thecarrier system 110 may be preferred. However, if execution of on-chainlogic is expensive for a particular blockchain network 100, then thesmart contract or other on-chain logic 220 of the carrier system 110 mayperform as little processing as possible to obtain and transmit dataregarding the API request 222 to the carrier node 112, which may thenperform more extensive processing off-chain to construct and execute anAPI request.

In some embodiments, the carrier node 112 may include various componentsor other subsystems for processing blockchain transaction data andgenerating API requests that are executable by the carrierinfrastructure 114. For example, as shown, the carrier node 112 mayinclude a blockchain network client 150 that interacts with theblockchain network 100 on behalf of the carrier system 100. Theblockchain network client 150 in this example may interact with theblockchain network via on-chain logic 220. Illustratively, theblockchain network client 150 may receive an API request 222 from theon-chain logic 220. A validation subsystem 152 can decrypt the APIrequest 222, if necessary, and validate the API request 222. Forexample, the validation subsystem 152 may deserialize the API request222 into a data structure that may be used by the carrierinfrastructure. A communication subsystem 154 may then package andtransmit the API request 230 to the appropriate carrier infrastructure114 for execution. In the example above, the carrier infrastructure maytransmit a telephony-based message (e.g., an SMS message) to a userdevice 130 via the telephony network 120.

In some embodiments, a message may not be able to be sent over atelephony network 120 without first authenticating and authorizing theoriginator of the message. For example, regulatory requirements fortelephony networks may include restrictions for sending messages overthe telephony network. Thus, outbound messages that are then sent as (orcause other messages to be sent as) telephony-based messages to userdevices 130 via the telephony network 120 may not be permitted by anyentity on the blockchain network 100 merely submitting an API request tothe carrier system 110. Rather, entities wishing to send such messagesmay be required to be authorized (“whitelisted”) by the carrier beforeany messages may be sent on behalf of the entities. For example, anentity may submit an API request via the blockchain network 100 ortransmit an offline API request to establish an account with the carriersystem 110. The entity may be required to provide identifyinginformation, address information, and the like to the carrier system110. The carrier system may store the data in a data store, and use thestored data to authenticate and authorize the entity to initiate thesending of messages via the telephony network 120 when a telephony-basedmessage is to be sent. Illustratively, the carrier system 110 may sendthe telephony-based message using the entity's phone number as theoriginating phone number of the message.

The message origins, transactions, on-chain logical processes, datatypes, and communications shown in FIG. 2 and described herein areillustrative only and are not intended to be limiting. In someembodiments, additional or alternatives may be used without departingfrom the scope of the present disclosure.

FIG. 3 shows example data flows and interactions between a blockchainnetwork 100 and other systems and networks during processing of acommunication directed to an on-chain logical processing component. Suchmessages may be referred to as “inbound messages” to highlight theirdirection as being inbound with respect to the blockchain network 100.

An entity, such as a company or individual person, may use a user device130 to interact with the blockchain network 100. The entity may wish toinvoke a particular function of the blockchain network, such as thetransfer of value from one account to another account upon theoccurrence of some condition. For example, the user device 130 may be anATM that has access to the telephony network 130, but no access to theinternet. In some cases, it may be possible for the ATM to establish aninternet connection using the telephony network 130. However, doing somay be expensive (e.g., if the telephony network is a cellular network),not sufficiently reliable, or may have other undesirable features oreffects. In comparison, transmitting a telephony-based message, such asan SMS message, may be faster, more reliable, less expensive, etc. Thus,the ATM may be configured to generate a blockchain network transactionmessage for transmission as a telephony-based message 300.

In some embodiments, as shown, the telephony-based message 300 may beformatted such that the blockchain network transaction therein may beeasily initiated from the message. For example, the content of thetelephony-based message 300 may be a serialized version of theblockchain transaction, including a data structure that is used nativelyby the blockchain network 100, or a serialized version of a datastructure that is used by the carrier system 120 to derive and broadcastthe transaction on the blockchain network 100. In some embodiments, thetelephony-based message 300 or a portion thereof may be encrypted orotherwise obfuscated to prevent unauthorized access to information inthe telephony-based message 300 (e.g., when the telephony-based message300 is sent as a text-based SMS message).

The blockchain transaction—however it is included in the telephony-basedmessage 300—may include various data elements that are used in executionof the blockchain transaction. For example, the telephony-based message300 may include data representing a source address 302 for theblockchain account that is initiating the blockchain transaction, suchas a user account or on-chain logic associated with the user device 130.The telephony-based message 300 may also include data identifying adestination address 304 of the blockchain transaction, such as on-chainlogic 320 of the carrier system 110. The telephony-based message 300 mayalso include data representing a value 306 to be transferred, such asthe value to be transferred to the carrier system 110 for providingblockchain network access services to the user device 130. The value 306may also include the value to be transferred to a separate account oron-chain logic associated with an entity other than the carrier system110, such as a separate destination 320 (e.g., the value 306 may be asum of the total value to be transferred from the account associatedwith the source address 302). The telephony-based message 300 may alsoinclude a payload 308 that represents a second blockchain transaction tobe initiated by on-chain logic 310 of the carrier system 110 (e.g., datarepresenting a source account from which value is to be removed, adestination account to which value is to be added, a payload includingdata representing a condition upon which the transfer of value is to becompleted or invocation of a function of the destination on-chain logic,etc.). The on-chain logic 310 of the carrier system 110 is to providethe second blockchain transaction to the blockchain network 110 andultimately to a destination 320. The payload 308 may be formatted in amanner such that the second blockchain network transaction may easily beinitiated from the data. For example, the payload 308 may be aserialized version of a signed second blockchain transaction, includinga data structure that is used natively by the blockchain network 100, orserialized version of a data structure that is used by the carrieron-chain logic 310 to initiate a blockchain network transaction.

In some embodiments, the telephony-based message 300 may include datathat is used by the on-chain logic 310 of the carrier system to initiatea blockchain transaction, without the telephony-based message itselfincluding a blockchain transaction. For example, the telephony-basedmessage 300 may include a data structure with the data elements (e.g.,source, destination, value, payload) that are to be used by the carriernode 112 or on-chain logic 310 to generate and provide a blockchaintransaction to the blockchain network 100 and ultimately to thedestination 320. In these cases, the carrier system 110 may maintain aprivate key, associated with the source account 302, to use in signingthe blockchain transaction for submission to the blockchain network 100.

The user device 130 may transmit the telephony-based message to thecarrier system 110 via the telephony network 120. The user device 130may address the telephony-based message using a telephone numberassociated with the carrier system 110, the blockchain network 100, etc.In some embodiments, the telephone number may be a general phone numberused to send any type of message to the blockchain network 100 or tosend any type of message to the carrier system 100. The telephony-basedmessage may be routed by telephony system 120 to the carrier system 110.The carrier system infrastructure 114 may receive and perform anynecessary processing on the message to determine that the messageincludes a communication to the blockchain network 100. For example, thedestination address may be assigned to the blockchain network. Asanother example, an identifier within the message (e.g., a code withinthe payload or some other portion of the message) may identify themessage as being directed to the blockchain network. Once the message isidentified as being directed at the blockchain network 100, the carrierinfrastructure 114 may provide the message to the carrier node 112.

The carrier node 112 of the carrier system 110 may include a blockchainnetwork client 150 that is used to communicate with the blockchainnetwork 100. The blockchain network client 150 may perform processing onthe telephony-based message 300, if required. For example, theblockchain network client 150 may deserialize or otherwise process thecontents of the telephony-based message 300. The blockchain networkclient 150 may generate or otherwise obtain the blockchain transactiondata that will be used by the blockchain network 100 to process ablockchain transaction. The blockchain network client 150 may addressthe blockchain transaction to the carrier's on-chain logic 310, or theblockchain transaction may already be so addressed (e.g., when generatedby the user device 130). The blockchain network client 150 may thenprovide the blockchain transaction data to the blockchain network 100.

Once the blockchain transaction data is submitted to the blockchainnetwork 100, it may be detected by, received by, obtained by, orotherwise cause invocation of, carrier on-chain logic 310 for executionof the blockchain transaction. Carrier on-chain logic 310 may be a smartcontract that performs further logical processing of the blockchaintransaction. For example, carrier on-chain logic 310 may obtain andreserve the carrier system's portion of the value 302, and extractblockchain transaction data 312 from the payload data 308 prior tosending the blockchain transaction data 312 to a destination 320 on theblockchain network. The carrier on-chain logic 310 may then emit anevent on the blockchain network 100 or otherwise cause the transmissionof the blockchain transaction data 312 to the destination 320. In someembodiments, carrier on-chain logic 310 is deployed to the blockchainand is therefore part of the blockchain network 100. Illustratively, theon-chain logic (e.g., smart contract) may represented by code that maybe stored in the blockchain 102. When a message or other transactioninvokes the on-chain logic 310, the code is executed by one or moreentities of the blockchain network 100, such as the carrier node 112,one or more peer nodes 104, etc.

The blockchain transaction data 312 may include data representing avalue 314, a data payload 316 that is used by the destination 320 toperform on-chain or off-chain logical processing, other data, somecombination thereof, etc. The destination 320 may include on-chainlogic, such as a separate smart contract that performs certainprocessing related to the blockchain transaction (e.g., holding valueuntil a condition is met, and then transferring the value to anaccount). In some embodiments, the destination 320 may be a blockchainaccount that receives the blockchain transaction data 312 and proceedsaccordingly (e.g., recording information in the blockchain).

The message destinations, transactions, on-chain logical processes, datatypes, and communications shown in FIG. 3 and described herein areillustrative only and are not intended to be limiting. In someembodiments, additional or alternatives may be used without departingfrom the scope of the present disclosure.

Example Communications without Carrier System On-Chain Logic

FIG. 4 shows example data flows and interactions between a blockchainnetwork 100 and other systems and networks during processing of anoutbound communication directed to an off-chain user device 130. Incontrast to the interactions shown in FIG. 2, the interactions shown inFIG. 4 occur without using on-chain logic of a carrier system 110. Inthis way, the costs of processing such communications may be reduced inblockchain networks that require payment for execution of on-chainlogic. Additionally, or alternatively, omitting on-chain logic of thecarrier system 110 can in some cases simplify implementation. As long asthe blockchain network 100 allows sending messages with data payloads,then entities on the blockchain network 100 may access off-chainprocessing and services provided by the carrier system 100 by providingmessages with data payloads representing the operations to be performed(e.g., a serialized API call or other data used by the carrier system toperform functions).

Illustratively, an entity such as a company or individual person maywish employ the services of the carrier system 110 to send one or moretelephony messages. For example, the entity may wish to havetelephony-based messages transmitted to one or more user devices 130 inresponse to the occurrence of an event. The entity may use variousfeatures of the blockchain network 100 to monitor for the occurrence ofthe event. In response to detection of the event, the entity maytransmit blockchain communication with a data payload representing anAPI request. The blockchain communication may be received and acted uponby the carrier system 110.

The entity may establish a message origin 410 on the blockchain network100 that may include on-chain logic. In some embodiments, the on-chainlogic may be on-chain logic (e.g., a smart contract) that monitors forthe occurrence of the desired event and, in response to detectingoccurrence of the event, automatically generates blockchain message data412. The blockchain message data 412 may include data representing apayment 414 (e.g., the value to be paid to the carrier system 110 forproviding message transmission service to the message origin 410). Theblockchain message data 412 may also include data representing an APIrequest 416 to be executed by the carrier system 110.

The blockchain message data 412 may be provided to the carrier account420 that is on the blockchain network. In contrast to providing theblockchain message data 412 to carrier on-chain logic (as shown in FIG.2, and described above), providing the blockchain message data 412 tothe carrier account 420 may limit or prohibit on-chain processing of theblockchain message data 412. Rather than processing the blockchainmessage data 412 using on-chain logic, the data payload of theblockchain message data 412—the API request 416 in this example—may beaccessed as API request data 422 by the carrier node 112 and processedoff-chain.

The carrier node 112 may extract data representing an API request fromthe API request data 422. For example, the carrier node may deserializean API request, or the carrier node 112 may perform more intensiveprocessing to generate the API request from the API request data 422. Insome embodiments, the carrier node 112 may include various components orother subsystems for processing blockchain message data 412 andgenerating API requests that are executable by the carrierinfrastructure 114. For example, as shown, the carrier node 112 mayinclude a blockchain network client 150 that interacts with theblockchain network 100 on behalf of the carrier system 100. Theblockchain network client 150 in this example may interact with theblockchain network via on-chain account 420. Illustratively, theblockchain network client 150 may receive an API request data 422 fromthe on-chain carrier account 420. A validation subsystem 152 can decryptthe API request 422, if necessary, and validate the API request 422. Forexample, the validation subsystem 152 may deserialize the API request422 into a data structure that may be used by the carrierinfrastructure. A communication subsystem 154 may then package andtransmit the API request 430 to the appropriate carrier infrastructure114 for execution. In the example above, the carrier infrastructure maytransmit one or more telephony-based messages to one or more userdevices 130.

The message origins, transactions, on-chain accounts, off-chainprocessing, data types, and communications shown in FIG. 4 and describedherein are illustrative only and are not intended to be limiting. Insome embodiments, additional or alternatives may be used withoutdeparting from the scope of the present disclosure.

FIG. 5 shows example data flows and interactions between a blockchainnetwork 100 and other systems and networks during processing of aninbound communication. In contrast to the interactions shown in FIG. 3,the interactions shown in FIG. 5 occur without using on-chain logic of acarrier system 110.

An entity, such as a company or individual person, may use a user device130 to interact with the blockchain network 100. The entity may wish toinvoke a particular function of the blockchain network, such as thetransfer of value from one account to another account upon theoccurrence of some condition. The user device 130 may provide a firsttelephony-based message regarding payment 502 to the carrier system 110.For example, the first telephony-based message may include datarepresenting a first signed blockchain network transaction fortransferring value to the carrier system 110 (e.g., source account,destination account, value to be transferred, payload if necessary). Theuser device 130 may provide a second telephony-based message 504 to beprocessed by the carrier system 110 and submitted to a separate on-chainaccount or on-chain logic. For example, the second telephony-basedmessage 504 may include data representing a second signed blockchainnetwork transaction addressed to the destination 530 account or on-chainlogic (e.g., source account, destination account, value to betransferred, payload if necessary).

In some embodiments, the carrier system 110 may process the payment 502prior to receiving telephony-based message 504, or prior to processingtelephony-based message 504 for submission to the blockchain network100. For example, the carrier node 112 of the carrier system 110 mayenter the payment 512 on the blockchain network 100, and may wait forthe transfer of value to the carrier's on-chain account 520 beforeproceeding with processing of telephony-based message 504.Illustratively, the carrier node 112 may wait until the transfer ofvalue to the carrier account 520 has been recorded in the immutabledistributed ledger of the blockchain network 100 before proceeding.

The telephony-based message 504 may include various data elements thatare used in the transmission and execution of a blockchain transaction.For example, the telephony-based message 504 may include datarepresenting a destination address of the blockchain transaction, anddata representing a value to be transferred. The telephony-based message504 may also include a payload that represents the blockchaintransaction (e.g., data that causes invocation of a smart contractfunction, data representing a source account from which value is to beremoved, data representing a destination account to which value is to beadded, data representing a condition upon which the transfer of value isto be completed, etc.).

The carrier node 112 may generate, extract, or otherwise obtainblockchain transaction data 514 from the telephony-based message 504.For example, the carrier node 112 may generate transaction data 514 thatrepresents value 516 to be transferred, and a payload 518.Illustratively, the telephony-based message 504 may be formatted in amanner such that a blockchain network transaction may easily begenerated from the data. For example, the payload telephony-basedmessage 504 may include a serialized version of a data structure that isused natively by the blockchain network 100, or serialized version of adata structure that is used by the carrier system 110 to initiate ablockchain network transaction.

The blockchain network client 150 may then provide the blockchaintransaction data 514 to the blockchain network 100, where it isdetected, received, or otherwise obtained by the destination 530 towhich the blockchain transaction data is addressed. The destination 530may be on-chain logic for execution of the blockchain transaction. Forexample, the on-chain logic 530 may be a smart contract that performsfurther logical processing of the blockchain transaction.

The message destinations, transactions, on-chain logical processes, datatypes, and communications shown in FIG. 5 and described herein areillustrative only and are not intended to be limiting. In someembodiments, additional or alternatives may be used without departingfrom the scope of the present disclosure.

Example Communications Using Payment Channels

Payment channels can be implemented as a means to support fast paymentsfrom users and off-chain applications. In some embodiments,implementation of a payment channel requires the carrier system 110 tohave also implemented support for payment by tokens (e.g.,cryptocurrency value) on the blockchain network 100. For example, thecarrier system 110 may deploy on-chain logic, such as a smart contract.An entity that desires to use the services of the carrier system 110 candeposit a balance into the smart contract, and the smart contract maymaintain the value and prohibit access to the value by either party(message origin or carrier system) until the payment channel is settled.During this time, the message origin can transfer value to the carriersystem instantly through an off-chain payment channel.

FIG. 6 shows example data flows and interactions between a blockchainnetwork 100 and other systems when using a payment channel. In someembodiments, an entity such as a company or individual may wish toinvoke off-chain functionality of the carrier system 110. The entity maytransfer value 602 from the entity account 600 to carrier systemon-chain logic 610. In addition, a peer node 104 of the entity may sendan API request 630 to the carrier system's carrier node 112, which mayprocess the API request 630 off-chain. Once the payment channel hassettled, a settlement 612 may be provided to the carrier's on-chainaccount 620.

FIG. 7 shows example data flows and interactions between a blockchainnetwork 100 and other systems and networks, including a payment channel,during processing of an inbound communication. An entity, such as acompany or individual person, may use a user device 130 to interact withthe blockchain network 100. The entity may wish to invoke a particularfunction of the blockchain network, such as the transfer of value fromone account to another account upon the occurrence of some condition.The user device 130 may provide a first telephony-based messageregarding payment 702 to the carrier system 110. The user device 130 mayprovide a second telephony-based message 704 to be processed by thecarrier system 110 and submitted to a separate on-chain account oron-chain logic.

The carrier node 112 may initiate a payment transaction based on thepayment message 702. Illustratively, the payment transaction may resultin the transfer of value 712 from the user's account 710 to carriersystem on-chain logic 720 as payment for subsequently providingblockchain network access services. In this way, the carrier system 110allows the user device 130 to subsequently submit messages to theblockchain network 100 through the carrier system 110 without anypayment related delays. The carrier system on-chain logic 720 may holdthe value for any length of time as advance payment for providingblockchain network access services to the user device 130, and thecarrier system on-chain logic 720 may settle the account at any timebased on the performance of services. Carrier node 112 may initiate aseparate blockchain transaction by providing blockchain transaction data740 to the blockchain network 100, where it is detected, received, orotherwise obtained by a destination 750, such as on-chain logic or ablockchain account for the target of the message. In addition, once thepayment channel has settled, a settlement 722 may be provided to thecarrier's on-chain account 730.

Example Processes

FIG. 8 is a flow diagram of an illustrative process 800 that may beexecuted by a carrier system 110 to process telephony-based messages andgenerate blockchain network communications.

The process 800 begins at block 802. When the process 800 is initiated,a set of executable program instructions stored on one or morenon-transitory computer-readable media (e.g., hard drive, flash memory,removable media, etc.) may be loaded into memory (e.g., random accessmemory or “RAM”) of a computing device of the carrier system 110, suchas the computing device 1000 shown in FIG. 10 and described in greaterdetail below. The executable instructions may then be executed by ahardware-based computer processor (e.g., a central processing unit or“CPU”) of the computing device. In some embodiments, the process 800 orportions thereof may be implemented on multiple processors, serially orin parallel.

At block 804, the carrier system 110 can receive one or moretelephony-based messages representing a blockchain networkcommunication, as described in greater detail above. A singletelephony-based message may include data representing the blockchainnetwork communication. In some embodiments, telephony-based messages maybe limited in the amount or type of data that may be transmitted. Forexample, SMS messages have a limit of 160 characters, and messagesexceeding 160 characters will be segmented into multiple messages suchthat each individual segmented message of the set of segmented messagesis less than or equal to the size limit. In some embodiments, dependingon the size of a telephony-based message that a user device 130 is totransmit to the carrier system 110, the user device 130 may generate acompressed version of the message content (e.g., using a losslesscompression algorithm). For example, if the user device 130 determinesthat the size of the message may be compressed to fit within a singleSMS message without segmentation, then the user device 130 may generatea compressed version of the message for transmission to the carriersystem. Upon receipt of the compressed message, the carrier system 110may determine that the message has been compressed and may decompressthe message before proceeding with processing. In some cases, messagesegmentation is unavoidable. To handle such cases, the carrier system110 can support segmentation. For example, the carrier system 110 maydetect that a plurality of recently-received telephony-based messagesare segments of a single message, or that a received telephony-basedmessage is the first segment of multiple segments and should not beprocessed separately. Illustratively, the determination may be based ona sequence identifier or other indicator included in the message, on amanifest that is sent with or separately from the segments, etc. Onceall segments have been received, the carrier system 110 may splice thesegments together to recover the original message and proceed withprocessing. In some embodiments, a user device 130 may use analternative telephony-based protocol (e.g., MMS) when sending a messagethat exceeds the limits of a preferred telephony-based protocol.

At block 806, the carrier system 110 can generate a blockchain networkcommunication using the received telephony-based message(s) as describedin greater detail above.

At block 808, the carrier system 110 can communicate the blockchainnetwork communication over the blockchain network as described ingreater detail above. The process 800 may then terminate at block 810.

FIG. 9 is a flow diagram of an illustrative process 900 that may beexecuted by a carrier system 110 to process a blockchain networkcommunication and generate a telephony-based message.

The process 900 begins at block 902. When the process 900 is initiated,a set of executable program instructions stored on one or morenon-transitory computer-readable media (e.g., hard drive, flash memory,removable media, etc.) may be loaded into memory (e.g., random accessmemory or “RAM”) of a computing device of the carrier system 110, suchas the computing device 1000 shown in FIG. 10 and described in greaterdetail below. The executable instructions may then be executed by ahardware-based computer processor (e.g., a central processing unit or“CPU”) of the computing device. In some embodiments, the process 900 orportions thereof may be implemented on multiple processors, serially orin parallel.

At block 904, the carrier system 110 can receive a blockchain networkcommunication over a blockchain network as described in greater detailabove.

At block 906, the carrier system 110 can process the blockchain networkcommunication to generate an API request, for a function provided by thecarrier system API, as described in greater detail above. In someembodiments, templates for telephony-based messages may be used to cutdown on the amount of data handled by the blockchain network 100. Forexample, the carrier system 110 may provide a selection of messagetemplates for use by entities that send messages via the carrier system110, or entities may provide their own templates to the carrier system110. The templates may be associated with unique identifiers. An entitymay submit an API request to the carrier system 110 via the blockchainnetwork to send a message to an end user device 130. Rather thanincluding the entire contents of the message in the API request that iscommunicated via the blockchain network 100, the entity may reference atemplate identifier in the API request. The carrier system 110 canaccess the previously-stored template information for the identifier andprocess the API request accordingly.

In some embodiments, a template may include one or more dynamic portionsthat are customizable from message-to-message. An entity may include thedynamic portions in the API request, along with the template identifier.The carrier system 110 can use the provided dynamic portions along withthe corresponding template when fulfilling the API request. For example,an entity may generate (or cause generation of) blockchain message datathat includes one or more template identifiers, contact information oridentifiers for one or more recipients, and dynamic portions to beincluded in the template. The carrier system 110 can load the identifiedtemplate(s), add the dynamic portion(s) to the template(s), and send atelephony-based message to one or more recipients.

In some cases, it is not viable to store contact lists and othersensitive information on the blockchain network 100, as this storage canbe costly and a security risk. The carrier system 110 can store suchdata off-chain and along with identifiers to be included in API requestsinstead. For example, an entity may provide a list of contactinformation (e.g., phone numbers) and corresponding identifiers to thecarrier system 110 in an off-chain communication. Then, when submittingan API request to send a telephony-based message to a particular enduser, the entity may include the identifier of the entity in the APIrequest rather than the actual contact information for the end user. Thecarrier system 110 can access the previously-stored contact informationfor the identifier and process the API request accordingly. In the casethat a particular application requires sensitive data to be present onthe blockchain network 100, the carrier system 110 can provide publickeys for encryption prior to submission on-chain. For example, entitiescan encrypt a message payload prior to submission to the blockchainnetwork 100, and the carrier node 112 or other carrier infrastructurecan decrypt the payload when fulfilling an API request.

At block 910, the carrier system 110 can transmit the telephony-basedmessage over the telephony as described in greater detail above. Theprocess 800 may then terminate at block 912.

Example Computing Device

FIG. 10 illustrates the various components of an example computingdevice 1000 configured to implement some or all of the functionality ofa carrier system 110. In some embodiments, as shown, the computingdevice 1000 may include: one or more computer processors 1002, such asphysical central processing units (“CPUs”); one or more networkinterfaces 1004, such as a network interface cards (“NICs”); one or morecomputer readable medium drives 1006, such as a high density disks(“HDDs”), solid state drives (“SDDs”), flash drives, and/or otherpersistent non-transitory computer-readable media; an input/outputdevice interface 1008, such as an IO interface in communication with oneor more microphones; and one or more computer readable memories 1010,such as random access memory (“RAM”) and/or other volatilenon-transitory computer-readable media.

The computer readable memory 1010 may include computer programinstructions that one or more computer processors 1002 execute in orderto implement one or more embodiments. The computer readable memory 1010can store an operating system 1012 that provides computer programinstructions for use by the computer processor(s) 1002 in the generaladministration and operation of the computing device 1000. In someembodiments, the computer readable memory 1010 can further includecomputer program instructions and other information for implementingaspects of the present disclosure. For example, in one embodiment, thecomputer-readable memory 1010 may include network client instructions1014 for implementing features of the network client 150, validationsubsystem instructions 1016 for implementing features of the validationsubsystem 152, communication subsystem instructions 1018 forimplementing features of the communication subsystem 154, instructionsfor implementing other features, or some combination thereof.

Terminology

Depending on the embodiment, certain acts, events, or functions of anyof the processes or algorithms described herein can be performed in adifferent sequence, can be added, merged, or left out altogether (e.g.,not all described operations or events are necessary for the practice ofthe algorithm). Moreover, in certain embodiments, operations or eventscan be performed concurrently, e.g., through multi-threaded processing,interrupt processing, or multiple processors or processor cores or onother parallel architectures, rather than sequentially.

The various illustrative logical blocks, modules, routines, andalgorithm steps described in connection with the embodiments disclosedherein can be implemented as electronic hardware, or combinations ofelectronic hardware and computer software. To clearly illustrate thisinterchangeability, various illustrative components, blocks, modules,and steps have been described above generally in terms of theirfunctionality. Whether such functionality is implemented as hardware, oras software that runs on hardware, depends upon the particularapplication and design constraints imposed on the overall system. Thedescribed functionality can be implemented in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the disclosure.

Moreover, the various illustrative logical blocks and modules describedin connection with the embodiments disclosed herein can be implementedor performed by a machine, such as a computer processor device, adigital signal processor (DSP), an application specific integratedcircuit (ASIC), a field programmable gate array (FPGA) or otherprogrammable logic device, discrete gate or transistor logic, discretehardware components, or any combination thereof designed to perform thefunctions described herein. A processor device can be a microprocessor,but in the alternative, the processor device can be a controller,microcontroller, or state machine, combinations of the same, or thelike. A processor device can include electrical circuitry configured toprocess computer-executable instructions. In another embodiment, aprocessor device includes an FPGA or other programmable device thatperforms logic operations without processing computer-executableinstructions. A processor device can also be implemented as acombination of computing devices, e.g., a combination of a DSP and amicroprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration. Although described herein primarily with respect todigital technology, a processor device may also include primarily analogcomponents. For example, some or all of the algorithms described hereinmay be implemented in analog circuitry or mixed analog and digitalcircuitry. A computing environment can include any type of computersystem, including, but not limited to, a computer system based on amicroprocessor, a mainframe computer, a digital signal processor, aportable computing device, a device controller, or a computationalengine within an appliance, to name a few.

The elements of a method, process, routine, or algorithm described inconnection with the embodiments disclosed herein can be embodieddirectly in hardware, in a software module executed by a processordevice, or in a combination of the two. A software module can reside inRAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory,registers, hard disk, a removable disk, a CD-ROM, or any other form of anon-transitory computer-readable storage medium. An exemplary storagemedium can be coupled to the processor device such that the processordevice can read information from, and write information to, the storagemedium. In the alternative, the storage medium can be integral to theprocessor device. The processor device and the storage medium can residein an ASIC. The ASIC can reside in a user terminal. In the alternative,the processor device and the storage medium can reside as discretecomponents in a user terminal.

Conditional language used herein, such as, among others, “can,” “could,”“might,” “may,” “e.g.,” and the like, unless specifically statedotherwise, or otherwise understood within the context as used, isgenerally intended to convey that certain embodiments include, whileother embodiments do not include, certain features, elements and/orsteps. Thus, such conditional language is not generally intended toimply that features, elements and/or steps are in any way required forone or more embodiments or that one or more embodiments necessarilyinclude logic for deciding, with or without other input or prompting,whether these features, elements and/or steps are included or are to beperformed in any particular embodiment. The terms “comprising,”“including,” “having,” and the like are synonymous and are usedinclusively, in an open-ended fashion, and do not exclude additionalelements, features, acts, operations, and so forth. Also, the term “or”is used in its inclusive sense (and not in its exclusive sense) so thatwhen used, for example, to connect a list of elements, the term “or”means one, some, or all of the elements in the list.

Disjunctive language such as the phrase “at least one of X, Y, Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z).Thus, such disjunctive language is not generally intended to, and shouldnot, imply that certain embodiments require at least one of X, at leastone of Y, or at least one of Z to each be present.

Unless otherwise explicitly stated, articles such as “a” or “an” shouldgenerally be interpreted to include one or more described items.Accordingly, phrases such as “a device configured to” are intended toinclude one or more recited devices. Such one or more recited devicescan also be collectively configured to carry out the stated recitations.For example, “a processor configured to carry out recitations A, B andC” can include a first processor configured to carry out recitation Aworking in conjunction with a second processor configured to carry outrecitations B and C.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it can beunderstood that various omissions, substitutions, and changes in theform and details of the devices or algorithms illustrated can be madewithout departing from the spirit of the disclosure. As can berecognized, certain embodiments described herein can be embodied withina form that does not provide all of the features and benefits set forthherein, as some features can be used or practiced separately fromothers. The scope of certain embodiments disclosed herein is indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

1.-20. (canceled)
 21. A computer-implemented method comprising: asimplemented by a computing system comprising one or more computerprocessors configured to execute specific instructions, receiving atelephony-based message from a computing device over a telephonynetwork, wherein the telephony-based message is addressed to a firstphone number and comprises one of a short message service (“SMS”)message or a multimedia messaging service (“MMS”) message, and whereinthe telephony-based message comprises a data payload; determining ablockchain network communication data structure based at least partly onthe data payload of the telephony-based message, wherein the blockchainnetwork communication data structure is associated with a destinationblockchain network address of a smart contract on a blockchain network;and communicating the blockchain network communication data structureover the blockchain network to the smart contract using the destinationblockchain network address, wherein the smart contract obtains theblockchain network communication data structure over the blockchainnetwork.
 22. The computer-implemented method of claim 21, whereindetermining the blockchain network communication data structure from thedata payload comprises extracting the blockchain network communicationdata structure from the data payload.
 23. The computer-implementedmethod of claim 21, wherein determining the blockchain networkcommunication data structure from the data payload comprisesdeserializing a serialized version of the blockchain networkcommunication data structure.
 24. The computer-implemented method ofclaim 21, further comprising receiving a second blockchain networkcommunication data structure comprising a second data payload, whereinthe second data payload represents a second telephony-based text messageto be sent over the telephony network.
 25. The computer-implementedmethod of claim 24, further comprising authenticating an originator ofthe second telephony-based message based at least partly on identifyinginformation associated with the originator.
 26. The computer-implementedmethod of claim 25, further comprising: authorizing the originator ofthe second telephony-based message based at least partly on theidentifying information, wherein the identifying information representsan account associated with a telephony network carrier; and sending thesecond telephony-based text message over the telephony network.
 27. Thecomputer-implemented method of claim 26, wherein authorizing theoriginator comprises verifying an existence of the account using theidentifying information.
 28. The computer-implemented method of claim21, further comprising determining a source blockchain account to beused as a source of the blockchain network communication data structureto be communicated to the smart contract.
 29. The computer-implementedmethod of claim 21, further comprising receiving a secondtelephony-based message from the computing device over the telephonynetwork, wherein the data payload of the telephony-based messagecomprises a first segment of the blockchain network communication datastructure, and wherein a second data payload of the secondtelephony-based message comprises a second segment of the blockchainnetwork communication data structure.
 30. The computer-implementedmethod of claim 29, wherein determining the blockchain networkcommunication data structure comprises appending at least part of thesecond segment to at least part of the first segment.
 31. Thecomputer-implemented method of claim 21, wherein communicating theblockchain network communication data structure comprises causinginvocation of the smart contract to process the blockchain networkcommunication data structure on the blockchain network.
 32. A systemcomprising: computer-readable memory storing executable instructions;and one or more processors in communication with the computer-readablememory and configured by the executable instructions to at least:receive a telephony-based message from a computing device over atelephony network, wherein the telephony-based message is addressed to afirst phone number and comprises one of a short message service (“SMS”)message or a multimedia messaging service (“MMS”) message, and whereinthe telephony-based message comprises a data payload; determine ablockchain network communication data structure based at least partly onthe data payload of the telephony-based message, wherein the blockchainnetwork communication data structure is associated with a destinationblockchain network address of a smart contract on a blockchain network;and communicate the blockchain network communication data structure overthe blockchain network to the smart contract using the destinationblockchain network address, wherein the smart contract obtains theblockchain network communication data structure over the blockchainnetwork.
 33. The system of claim 32, wherein to determine the blockchainnetwork communication data structure from the data payload, the one ormore processors are further configured by the executable instructions toextract the blockchain network communication structure from the datapayload.
 34. The system of claim 32, wherein to determine the blockchainnetwork communication data structure from the data payload, the one ormore processors are further configured by the executable instructions todeserialize a serialized version of the blockchain network communicationdata structure.
 35. The system of claim 32, wherein the one or moreprocessors are further configured by the executable instructions toreceive a second blockchain network communication data structurecomprising a second data payload, wherein the second data payloadrepresents a second telephony-based text message to be sent over thetelephony network.
 36. The system of claim 35 wherein the one or moreprocessors are further configured by the executable instructions to:authorize an originator of the second telephony-based message based atleast partly on identifying information, wherein the identifyinginformation represents an account associated with a telephony networkcarrier, and wherein the identifying information is used to verify anexistence of the account; and send the second telephony-based textmessage over the telephony network.
 37. The system of claim 32, whereinthe one or more processors are further configured by the executableinstructions to determine a source blockchain account to be used as asource of the blockchain network communication data structure.
 38. Thesystem of claim 32, wherein the one or more processors are furtherconfigured by the executable instructions to receive a secondtelephony-based message from the computing device over the telephonynetwork, wherein the payload of the telephony-based message comprises afirst segment of the blockchain network communication data structure,and wherein the a second payload of the second telephony-based messagecomprises a second segment of the blockchain network communication datastructure.
 39. The system of claim 38, wherein the blockchain networkcommunication data structure is determined based at least partly on thefirst segment and the second segment.
 40. The system of claim 32,wherein to communicate the blockchain network communication datastructure, the one or more processors are further configured by theexecutable instructions to cause invocation of the smart contract toprocess the blockchain network communication data structure on theblockchain network.